\section{User-Centered Design}
A big focus for the fourth semester of Medialogy is the development of user-centered designs. This section will look into how the design process should be structured and why it is important to include the user in it. The following is based on the book \textit{Interaction Design - beyond human-computer interaction} \cite{interactionDesign}.

When designing a product with an interface, some designers forget that the product they are making is built for the user - not the designer or programmer. A certain design might seem both logical, aesthetically pleasing and intuitive to the designer, but this does not mean that the user is of the same opinion. This is why it is important to include the user through the entire design process - from its early concept drafts to the final design.

\subsection{Gathering Data}
Already from the start it's important to know the needs of the user. The designer has an idea for a product and its target group, but should not feel certain at this point whether that idea is any good. Data needs to be gathered from the intended group to determine their needs and upon these construct the requirements for the design. Even though this first step is very important, it's limited how much can be concluded this early in the design process. There are five ways to gather data:

\begin{enumerate}
\item \textbf{Questionnaires:} Quantitative. Needs to be well-structured to give the right answers. Doesn't take much man-time to conduct, but might take time before sufficient answers are given.
\item \textbf{Interviews:} Mostly qualitative. Takes some time, depending on the amount of interviewees, but can give more personal and guided data.
\item \textbf{Focus groups:} Mostly qualitative. Helps determining requirements for the product through discussion. Takes some time.
\item \textbf{Observation:} Qualitative. Very time-consuming. Can give detailed insight into the target group and how they use (or would use) the product.
\item \textbf{Documentation:} Quantitative. Takes almost no time to conduct. Looks on data already gathered. Rarely useful data.
\end{enumerate}

Early on, a fairly unstructured interview could help point the design in the right direction. A questionnaire could also work, but an unstructured interview is faster, and it is harder to design the questions in a questionnaire properly to get the right answers this early in the design process. Furthermore, it's possible to look at an already-recorded documentation, but often this is so unspecified towards the product that it is rarely useful.

\subsection{Needs and Requirements}
Whichever approach for gathering data is chosen, a set of needs will be found. From these it's possible to construct requirements for the design. These requirements can be divided into two categories: \textit{functional requirements} and \textit{non-functional requirements}. The functional requirements are simply what the product is supposed to do; what the user expects to be possible with the product. This should not be confused with the designer's personal vision for the product. The non-functional requirements can be further divided into four subcategories:
\begin{enumerate}
\item \textbf{Data requirements:} what data does the program need to handle or access?
\item \textbf{Environmental requirements:}
\begin{enumerate}
\item What is the physical context?
\item What is the social context?
\item What is the organizational context?
\item What is the technical context?
\end{enumerate}
\item \textbf{User requirements:} does the product fit the target group? What is required to enjoy this product to its fullest?
\item \textbf{Usability requirements:} this will be looked more into in the next subsection.
\end{enumerate}

\subsection{Usability and User Experience}
\textit{Usability requirements} are a larger section all by itself. Usability can be divided into six categories:
\begin{enumerate}
\item \textbf{Effective to use (effectiveness):} does the program do what it is supposed to do? Does it have the expected functionality?
\item \textbf{Efficient to use (efficiency):} easy, simple and quick interface \textit{"[...] an efficient way of supporting common tasks is to let the user use single button or key presses."}\cite{interactionDesign}
\item \textbf{Safe to use (safety):} \textit{"[...] (i) preventing the user from making serious errors by reducing the risk of wrong keys/buttons being mistakenly activated (an example is not placing the quit or delete-file command right next to the save command on a menu)."}\cite{interactionDesign}
\item \textbf{Have good utility (utility):} can users do what they want to do? \textit{"Does the system provide an appropriate set of functions that enable users to carry out all their tasks in the way they want to do them?"}\cite{interactionDesign}
\item \textbf{Easy to learn (learnability):} \textit{"How easy is it and how long does it take (i) to get started using a system to perform core tasks and (ii) to learn the range of operations to perform a wider set of tasks?"}\cite{interactionDesign}
\item \textbf{Easy to remember how to use (memorability):} \textit{"What kinds of interface support have been provided to help users remember how to carry out tasks, especially for systems and operations that are used infrequently?"}
\end{enumerate}

Usability is about what the program should do, what it does, how it does it and how well it does it. All these are requirements, but they don't have a right or wrong answer. The only way to know whether a design is good is to make several design drafts and put them up against each other and show them to the target audience.

If usability is the logical requirements of the design, then \textit{user experience} is how the product feels. How a product feels is a big part of the design, but is a more abstract concept to grasp. Through the product the designer might want to evoke feelings such as fun, motivation or creativity. As with usability, this takes some balancing as some feelings work against each other. To determine whether the product evokes the proper feelings, participation from the users is required.

\subsection{Design Principles}
Designing a product is a mix of experience, theory, user data and common sense. To make the process more manageable are here some simple guidelines to follow. These do not explain directly what to do with a specific design, but act as rules of thumb to be aware of when designing a product. These guidelines served the group as pinpoints through the design process.
\begin{enumerate}
\item \textbf{Visibility:} the relationship between position and task. Easily visible and in a position that makes sense.
\item \textbf{Feedback:} works in unison with visibility. Quick and apparent feedback helps the user understand how to interact with a function.
\item \textbf{Constraints:}
\begin{enumerate}
\item \textbf{Physical:} physical constraints, like not being able to put a CD in a tablet or insert a floppy disk upside down.
\item \textbf{Logical:} constraints should be logical and easy to deduce through intuition. If for instance some options have been disabled, it should be apparent why and easy to understand.
\item \textbf{Cultural:} tradition and standard. A cross in the corner of a program closes the program. An exclamation mark means error. There can be different interpretations of colors, icons, symbols. Depends on the target group and existing software conventions.
\end{enumerate}
\item \textbf{Mapping:} the relationship between buttons, positions and effects. Buttons with similar functionality should be placed close to each other. A good example is the arrow keys on the keyboard: they do almost the same, but provide a different user experience. The difference is distinguishable through the buttons' logical placement next to each other.
\item \textbf{Consistency:} an action in one part of the program should be consistent through the entire program. This both helps in avoiding confusion with later elements of the program, when it doesn't do the same as before, and it helps learning the program, when everything can be learned bit for bit. When things become more complicated and broad, it's important to be able to categorize options. A good example of this is when right clicking an object with the mouse. The user knows that this should bring up options for the object, but doesn't need to know beforehand what options. Another example is when everyday experience/knowledge is applicable. A good example are folders in Windows: we know that physical folders contain things, have names, can be stored in other folders and can be categorized. All of this hold true for the digital version in Windows. Therefore, folders intuitively make sense.
\item \textbf{Affordances:} affordances is similar to logical constraints. When applied to physical interfaces, it simply describes what is physically possible to do with a thing and what is most logical. A button can only be pressed, which then becomes its logical function. When talking about software, this is more a question of conventions and habits, since there are no real constraints, which in turn makes it more related to consistency and cultural constraints. In other words: it's a perceived affordance.
\end{enumerate}